Compiling Purely Functional Structured Programs

We present a marriage of functional and structured imperative programming that embeds in pure lambda calculus. We describe how we implement the core of this language in a monadic DSL which is structurally equivalent to our intended source language and which, when evaluated, generates pure lambda terms in continuation-passing-style. 1. Pure Functional Programming One of the frequently touted benefits of being purely functional lies in the ease with which one can reason about programs. Pure functions have predictable and deterministic behaviour. Applying the same pure function to the same argument always yields the same result anywhere in code, thus allowing us to reason equationally about a program. But the lack of global variables and mutable state might be an impractical restriction for general purpose programming on conventional operating systems, and so it might be argued that it should be targeted to specific domains, such as the system configuration language Nix [5], where reproducibility of system builds is highly prized. Our own ProofScript [10] language is a new entry into the pure functional programming space, where the chosen domain is the development of large scale mechanical verifications of mathematics and software. Our model here is based on massive user collaboration, with users working within what is effectively a single development environment. In this environment, every mechanically verified theorem must be a piece of reproducible, immutable data, much like a Nix derivation. And so in our programming language, in which we write the code that produces the verified theorems, we seek the same discipline of pure functional programming. 2. Structured Programming Pure functional programming typically emphasises recursion and higher order functions for expressing complex control flow, and this level of abstraction can be intimidating to those coming from imperative backgrounds and more mainstream languages such as Python. However, the common imperative idioms from structured programming are not anathema to the aims of pure functional code. Indeed, the popu∗ This work has been funded by EPSRC Grant EP/L011794/1 larity of Static Single Assignment [4] (SSA) in compiler architectures shows that modelling imperative structured programming in a pure representation is of benefit when it comes to performing reliable optimisations and static analyses of code. ProofScript aims for the best of both worlds, marrying structured programming with a rich functional language whilst maintaining purity. We believe that our language bears a close affinity to the control flow model assumed in SSA, but with additional support for first-class functions and mutual recursion. Syntactically, basic ProofScript is a language with support for lexical scope, looping and assignment, but with the following key restrictions: 1. we do not support mutable cells as values; 2. closures close over the values of variables, not their locations; 3. function bodies can only assign to variableswhose lexical scope is contained in the function body. Rule 1 should not need additional explanation. Being able to create and pass around mutable storage locations means that the language encodes shared mutable state that can cross arbitrary regions of code. Rule 2 rules out situations such as: val x = 0 def get () = x val a = get () x = x + 1 val b = get () assert (a == b) Here, we have lost the referential transparency of the expression get (). The meaning of the function was changed by an imperative update. Rule 3 rules out common idioms from the world of impure functional programming such as the imperative (or object-oriented) counter: val counter = do val i = 0 def get () = i def incr () = i = i + 1 [get, incr]